Applicants' invention relates to systems and methods for providing a verifiable chain of evidence and security for the creation, execution, maintenance, transfer, retrieval and destruction of electronic original information objects, such as Electronic Original™ documents.
This invention advantageously uses Applicants' Trusted Custodial Utility that holds electronic original records and holds comparable system roles as a virtual electronic vault in validating the right of an individual to perform a requisite action, the authenticity of submitted electronic information objects, and the status of the authentication certificates used in the digital signature verification and user authentication processes. Such TCUs and operations are described in U.S. Pat. No. 5,615,268; U.S. Pat. No. 5,748,738; U.S. Pat. No. 6,237,096; and U.S. Pat. No. 6,367,013.
The following list of abbreviations is used in this description:
Abbreviations
CACertification AuthorityCRLCertificate Revocation ListCSSCertificate Status ServiceHTMLHypertext Markup LanguageIDIdentificationIETFInternet Engineering Task ForceITUInternational Telecommunications UnionLDAPLightweight Directory Access ProtocolOCSPOnline Certificate Status Protocol, IETF-RFC2560 X.509 Internet Public Key Infrastructure OnlineCertificate Status Protocol - OCSP, June 1999.PINPersonal Identification NumberPKCSPublic-Key Cryptographic StandardsPKIPublic Key InfrastructurePKIXPublic Key Infrastructure (X.509)S/MIMESecure Multi-Purpose Internet Mail ExtensionsSCVPSimple Certificate Validation Protocol,Draft-IETF-PKIX-SCVP-06, July 2000SSLSecure Socket LayerTCUTrusted Custodial UtilityUETAUniform Electronic Transactions ActXMLExtensible Markup Language
Legal standing for electronic signatures applied to information objects is made possible by the passage of U.S. Electronic Signatures in Global and National Commerce Act (ESIGN) legislation and U.S. state laws modeled after the UETA drafted by the National Conference of Commissioners on Uniform State Laws and approved and recommended for enactment in 1999 that has resulted in government, banking and electronic commerce activities aimed at realizing the efficiency and economies of these potentially wholly electronic transactions.
PKI and the CA are the base elements of digital signature technology used in creating electronic source records. A PKI is a collection of CAs where trust is established between users and user organizations by creating either a hierarchical relationship between CAs or through cross-certification amongst cooperating CAs. A CA is empowered to issue authentication certificates that bind an individual's or entity's identity to his or its public key (verifying), where only the individual is given access to the matching private key (signing). At the time of this application, certificates normally conform to the ITU X.509 certificate standard and are themselves digitally signed by the issuing CA. Such certificates are depicted in FIG. 10 of U.S. Pat. No. 6,237,096, for example, that is cited and incorporated above. These authentication certificates contain a serial number, identifying information of the subject (user) and issuer (CA), the certificate's validity period (date and time before and after which it may not be used), the subject's public key, and cryptographic algorithm information needed to create and verify digital signatures.
To create a digital signature, an information object is hashed (processed using a one-way cryptographic function that can detect as little as a one bit alteration in the object) and the hash is then encrypted using the individual's private (secret) key. Digital signature verification is achieved by reversing this process. The digital signature is decrypted using the individual's public key retrieved from their authentication certificate and the result is compared to a re-hash of the original information object. These processes may vary when using different digital signature algorithms. Digital signatures are only as reliable as the trust that exists between the relying parties and the issuing CAs; and the level of assurance achieved by the physical controls, practices and procedures implemented by the CAs.
The purpose of PKI technology is to create and maintain both a secure and trusted environment for communicating parties. Such parties rely on the PKI to establish the identity of users and to notify them when a user's certificate is no longer viable. Certificates are revoked when an individual leaves an organization, when a replacement certificate is issued, or when a signing key is lost, stolen or compromised. Vendors report certificate status using a wide variety of methods. These diverse methods make it more difficult for users to obtain certificate status for other users.
The formation of a trust relationship and interoperability is dictated by PKI certificate and security policies and their enforcement. The certificate policy determines the level of personal vetting (i.e., the process for validating appropriateness of certificate request information and the identity of the intended certificate recipient) required (e.g., two forms of picture ID, credit check) to gain approval for issuance of a certificate. The security policy dictates the physical, procedural and process controls needed to support the application environment.
There are two prevalent models for creating and organizing CAs. The first is a hierarchical CA model that resembles an inverted tree whose top is the root CA. The root CA signs its immediate subordinate CAs' certificates. These CAs then sign their subordinate CAs' certificates, and so on. These relationships create certificate chains that form branches of the tree. Two CAs prove that a trust relationship exists between them by “walking” their respective certificate chains until a common node is reached. CAs may be grouped and associated with one or more service delivery channels, industry verticals, organizations or enterprises.
In the second model, a CA is created for a single enterprise and provides CA services to one or more entities within that enterprise. An enterprise CA does not normally have any pre-established trust relationships with any CA of another enterprise. Explicit action must be taken to allow interoperability in the form of CA cross-certification, whereby two or more CAs that agree to trust one another sign each other's certificate and use these cross-certified certificates during digital signature verification. Certificates issued by one CA can then be validated by the other cross-certified CA and its users.
CAs revoke certificates when, among other reasons, the information contained therein becomes invalid, when the user's private key becomes compromised, or when it is necessary to terminate a user's certificate-based application privileges. CAs cannot simply delete or retrieve a certificate from its owner if it is already in the owner's possession. Instead, the certificate is marked as “revoked” in the CA's database and the certificate status is published. Users of the PKI can then learn of a certificate's validity by requesting certificate status from the issuing CA or identified status repository (directory).
An early method used to report certificate status was by way of publication of a list of a CA's revoked certificates, known as a CRL. CRLs are downloaded by applications and relying parties to determine whether a particular user's certificate has been revoked and by extension whether that user's digital signature is still valid or not. With time, CRLs get longer, incurring both communication and data processing overhead. An additional shortcoming of this approach is that CRLs are often published at infrequent intervals (e.g., once or twice a day). For this reason, CRLs are often immediately out-of-date after publication. Revoked certificates are only removed from CRLs after certificate expiration.
A PKI bridge is a method of providing interoperability between CAs by coordinating distribution of CRLs. Such a bridge is a central CRL repository that in effect joins a set of CAs that agree to accept each other's certificates and security policies. All CAs post their CRLs to the bridge. This allows for centralized validation of any individual's or entity's certificate. If the certificate has not been previously revoked, then it is still considered valid. The biggest disadvantage to PKI bridges is that they must be reachable by any CA or user relying on the bridge for certificate status. The bandwidth, computation, and storage requirements may be costly.
A more recent method for obtaining certificate status is the IETF OCSP, which makes a direct database query that can provide real-time certificate status. However, some vendors have implemented OCSP responders that are based on CRLs. Certificate status reported by this type of responder is only as timely as the CRLs on which they are based. Attempts to achieve real-time certificate status, such as the IETF SCVP continue to be developed. At the time of this invention, mixing and matching of status checking methods has not been practical in an open PKI environment.
Any approach to certificate validation is an all-or-nothing decision for the CA that issued the certificates. All users who are issued certificates by one of the member CAs are valid/enabled unless their certificate has been suspended or revoked or has expired. The common theme for controlling participation is whether a certificate gets issued. Issuance is governed by certificate and security policies and business rules.
The trust environment can range from fully open, where anyone able to pay the price of admission is issued a certificate, to closed or bounded, by requiring membership in an enterprise or community of interest. In either case, CA certificate and/or security policies govern whether interoperability is allowed.
Applicants' invention approaches the PKI and CA interoperability problem from a totally different point of view from those described above. Applicants' focus is on establishing a trust environment suitable for the creation, execution, maintenance, transfer, retrieval, and destruction of electronic original information objects that may also be transferable records (ownership may change hands). To realize these objectives, the system controlling an electronic original or authoritative copy must make it possible to identify the original from any copy thereof. As with paper originals, there can only be one original. Examples of transferable records are electronic negotiable instruments and securities. An electronic original record may be any source record, whether it qualifies as a transferable record or not. Transfer of electronic original records between systems must take place using methods that guarantee that only one original exists.
This invention creates an electronic original record by placing custody of that record in the hands of a trusted independent party, functionary or TCU operated for the benefit of the record's owner. Creating a trust environment is necessary, but is not sufficient for maintaining electronic source records. For the purposes of this invention, a trust environment is created by formation of a community of interest that has a closed or bounded membership and where the identity of prospective members, organizations and their users is assured by using appropriate vetting procedures that govern the granting of admission to the community. Further, an individual's organization, participation, role, and attributes are defined at the time of enrollment with the TCU. Individuals must be uniquely identified to the system and in their authentication certificate. In addition, it must be possible to remove individuals and organizations from the community and to make this action known to other members of the community. Traditional approaches to CA interoperability do not adequately achieve these objectives.
Vetting at a minimum requires that an organization and/or individual be sponsored by a known member of the community. In addition, a Dun and Bradstreet-like rating for organizations or an Equifax-like credit check for individuals, or an equivalent credit and payment history, may be utilized to evaluate acceptability of potential business partners, clients and customers. Both the vetting organization and its sponsored users must be deemed trustworthy before TCU enrollment is permitted. After an organization agrees to the contractual terms defining membership, its sponsored individuals will each be given a unique identifier and password that will enable them to access the TCU.
Once an individual is enrolled with one or more TCUs, they can be named as a participant to a transaction by the owner of that transaction and given specific access to all or an identified subset of source records based on their identity, role, and/or responsibility. To facilitate identification and authentication and to enable the transactions to take place in a totally electronic form, a selected subset of this identifying information is included in the participant's authentication certificate. The authentication certificate binds the user's identity with their public-key used to validate digital signatures generated using their matching signing private-key.
A certificate or security policy addresses the proof-of-identity requirements (e.g., two forms of picture ID, credit check, personal introduction) needed before issuing a certificate. This certificate will be bound to the user's TCU account if required for digital signing authority. The linkage shall include a subset of certificate data elements that uniquely identify the user (e.g., certificate ID, issuing CA name, user common name). Once associated with a user's account, the certificate can be used in conjunction with his or its digital signature to afford the proof-of-identity needed to enable a predetermined set of authorized actions and to verify the user's digital signature on submitted information objects. This is especially true when the owner or owner's agent controlling a set of electronic records instructs the TCU to transfer ownership (i.e., an internal transaction) and/or to transfer custody (i.e., an external transaction) of the electronic records to another TCU.
As described earlier, authentication certificates and public-key cryptography are used to support both user authentication and digital signature verification. The certificate is digitally signed by the issuing CA, a process by which the identity of the recipient is sealed with their public key. The CA asserts, in issuing a certificate, that the individual identified in the certificate is the holder of the matching private key used to digitally sign information objects or fragments thereof.
This invention differs from other PKI-based e-commerce solutions since the PKI is only viewed as enabling and is not the sole basis of the trust environment. Sponsorship, contracting for membership, and enrollment are the principal factors. Although the certificate and use of public-key cryptography are viewed as enabling technology, certificates must uniquely identify and be tied to the specific users before they can be bound to that user's TCU account.
Where certificates are employed, the account may only be activated once this binding between certificate and user account is completed. This binding may be as simple as adding the Certificate ID and Issuing CA to the user's account information or may use other information conveyed by the certificate such as components of the user's distinguished name (see ITU X.509 standard). The binding information may be conveyed in an enrollment form or extracted directly from the certificate as per TCU system security policy. A correspondence check may be used to ensure that the user description in the certificate matches that in the enrollment data whenever the certificate is used. The user's certificate is signed by the issuing CA and its integrity and authenticity are validated using the issuing CA's certificate and public key. The collective set of components used for identification must be provably unique. Once this TCU account and user certificate binding is accomplished, the TCU need only know where to go to check certificate status.
In CA centric environments, a single PKI, cross-certification, or creation of PKI bridges (a complex system that performs certificate status checking where multiple vendor products are used by numerous CAs) is required for interoperability. The common element is that all certificates are of equal value. Certificates may convey different trust levels and applications in an open environment must have the ability to interpret and use these trust levels differently. This philosophy can be characterized as “we will build roads that will take you anywhere you want to go”. Users are vetted upon CA enrollment using a variety of criteria (e.g., a credit check, means of payment, cost of the certificate).
A TCU, conversely, is only concerned with a known set of “approved CAs” and within that set only those certificates that are associated with its user accounts. Any other certificate will be ignored. This philosophy can be characterized as “the only roads that will be open to you will be those needed to conduct your business”. Users are vetted twice, once to satisfy the CA certificate policy and a second time to prove that there is a business need for them to be enrolled with a TCU. Business rules enforced by the TCU can accommodate certificates that are issued at different trust levels.